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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the MAC protocol. 
The specification describes: 
MAC architecture; 

- MAC entities; 
channel structure; 

services provided to upper layers; 

- MAC functions; 

services expected from the physical layer; 

elements for layer-to-layer communication including primitives between MAC and RLC; 

elements for peer-to-peer communication; 

- protocol data units, formats and parameters; 
elementary procedures. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 25.301 : "Radio Interface Protocol Architecture". 

[3] 3GPP TS 25.302: "Services provided by the Physical Layer". 

[4] 3GPP TS 25.303: "Interlayer Procedures in Connected Mode". 

[5] 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 

Mode". 

[6] 3GPP TS 25.322: "RLC Protocol Specification". 

[7] 3GPP TS 25.33 1 : "RRC Protocol Specification". 

[8] 3GPP TR 25.921: "Guidelines and Principles for Protocol Description and Error Handling". 

[9] 3GPP TR 25.990: "Vocabulary for the UTRAN". 

[10] 3GPP TS 33.102: "Security architecture". 

[II] 3GPP TS 25.425: "UTRAN lur Interface User Plane Protocols for Common Transport Channel 
Data Streams". 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in [9] and [1] apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ASC 


Access Service Class 


BCCH 


Broadcast Control Channel 


BCH 


Broadcast Channel 


C- 


Control- 


CCCH 


Common Control Channel 


CPCH 


Common Packet Channel (UL) 


DCCH 


Dedicated Control Channel 


DCH 


Dedicated Channel 


DL 


Downlink 


DSCH 


Downlink Shared Channel 


DTCH 


Dedicated Traffic Channel 


FACH 


Forward Link Access Channel 


FDD 


Frequency Division Duplex 


LI 


Layer 1 (physical layer) 


L2 


Layer 2 (data link layer) 


L3 


Layer 3 (network layer) 


MAC 


Medium Access Control 


PCCH 


Paging Control Channel 


PCH 


Paging Channel 


PDU 


Protocol Data Unit 


PHY 


Physical layer 


PhyCH 


Physical Channels 


RACH 


Random Access Channel 


RLC 


Radio Link Control 


RNC 


Radio Network Controller 


RNS 


Radio Network Subsystem 


RNTI 


Radio Network Temporary Identity 


RRC 


Radio Resource Control 


SAP 


Service Access Point 


SDU 


Service Data Unit 


SHCCH 


Shared Channel Control Channel 


SRNC 


Serving Radio Network Controller 


SRNS 


Serving Radio Network Subsystem 


TDD 


Time Division Duplex 


TFCI 


Transport Format Combination Indicator 


TFI 


Transport Format Indicator 


U- 


User- 


UE 


User Equipment 


UL 


Uplink 


UMTS 


Universal Mobile Telecommunications System 


USCH 


Uplink Shared Channel 


UTRA 


UMTS Terrestrial Radio Access 


UTRAN 


UMTS Terrestrial Radio Access Network 
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4 General 

4.1 Objective 

The objective is to describe the MAC architecture and the different MAC entities from a functional point of view. 

4.2 MAC architecture 

The description in this subclause is a model and does not specify or restrict implementations. 

According to the RRC functions the RRC is generally in control of the internal configuration of the MAC. 

4.2.1 IVIAC Entities 

The diagrams that describe the MAC architecture are constructed from MAC entities. 
The entities are assigned the following names. 

MAC-b is the MAC entity that handles the following transport channels: 

- broadcast channel (BCH) 

MAC-c/sh, is the MAC entity that handles the following transport channels: 

- paging channel (PCH) 
forward access channel (FACH) 

- random access channel (RACH) 

common packet channel (UL CPCH). The CPCH exists only in FDD mode, 
downlink shared channel (DSCH) 

- uplink shared channel (USCH). The USCH exists only in TDD mode. 
- MAC-d is the MAC entity that handles the following transport channels: 

dedicated transport channels (DCH) 

The exact functions completed by the entities are different in the UE from those completed in the UTRAN. 

NOTE: When a UE is allocated resources for exclusive use by the bearers that it supports the MAC-d entities 

dynamically share the resources between the bearers and are responsible for selecting the TFI/ TFCI that 
is to be used in each transmission time interval. 

4.2.2 IVIAC-b 

The following diagram illustrates the connectivity of the MAC-b entity in a UE and in each cell of the UTRAN. 

MAC-b represents the control entity for the broadcast channel (BCH). 

There is one MAC-b entity in each UE and one MAC-b in the UTRAN for each cell. 

The MAC Control SAP is used to transfer Control information to MAC-b. 

The MAC-b entity is located in the Node B. 
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BCCH Mac Control 




BCH 



Figure 4.2.2.1 : UE side and UTRAN side architecture 



4.2.3 Traffic Related Architecture - UE Side 

Figure 4.2.3.1 illustrates the connectivity of MAC entities. 

The MAC-c/sh controls access to common transport channels. 

The MAC-d controls access to dedicated transport channels. 

If logical channels of dedicated type are mapped to common channels then MAC-d passes the data to MAC-c/sh via the 
illustrated connection between the functional entities. 

The mapping of logical channels on transport channels depends on the multiplexing that is configured by RRC. 

The MAC Control SAP is used to transfer Control information to each MAC entity. 

PCCH BCCH CCCH CTCH SHCCH MAC Control DCCH DTCH DTCH 

(TDDonly I 



:W^^-^^^ 



-c> 



MAC-c/sh 



MAC-d 



PCH FACH FACH RACH CPCH USCH USCH DSCH DSCH DCH DCH 

( FDD only ) ( TDD only ) ( TDD only ) 

Figure 4.2.3.1 : UE side lUIAC architecture 



4.2.3.1 MAC-c/sh entity - UE Side 

Figure 4.2.3.1.1 shows the UE side MAC-c/sh entity. 



£75/ 



3GPP TS 25.321 version 3.6.0 Release 1999 10 ETSI TS 125 321 V3.6.0 (2000-12) 

The following functionality is covered: 

- TCTF MUX: 

this function represents the handling (insertion for uplink channels and detection and deletion for downlink 

channels) of the TCTF field in the MAC header, and the respective mapping between logical and transport 

channels. 

The TCTF field indicates the common logical channel type, or if a dedicated logical channel is used; 

- add/read UE Id: 

the UE Id is added for CPCH and RACH transmissions 

the UE Id, when present, identifies data to this UE. 

UL: TF selection: 

in the uplink, the possibility of transport format selection exists. 

In case of CPCH transmission, a TF is selected based on TF availability determined from status information 

on the CSICH; 

ASC selection: 

- For RACH, MAC indicates the ASC associated with the PDU to the physical layer. For CPCH, MAC may 
indicate the ASC associated with the PDU to the Physical Layer. This is to ensure that RACH and CPCH 
messages associated with a given Access Service Class (ASC) are sent on the appropriate signature(s) and 
time slot(s). MAC also applies the appropriate back-off parameter(s) associated with the given ASC; 

scheduling /priority handling 

this functionality is used to transmit the information received from MAC-d on RACH and CPCH based on 
logical channel priorities. This function is related to TF selection. 

TEC selection 

transport format and transport format combination selection according to the transport format combination 
set (or transport format combination subset) configured by RRC is performed. 

The RLC provides RLC-PDUs to the MAC, which fit into the available transport blocks on the transport channels. 

There is one MAC-c/sh entity in each UE. 
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SHOOH (TDD only) CCCH CTCH BCCH 



-J^ iiii 



TCTF MUX 



TFC 

selection 



MAC-c/sh 



add/read 
UE Id 



Scheduling/Priority 
Handling (1) 



UL: TF selection 



ASC 

selection 



ASC 
selection (2) 



PCH DSCH DSCH USCH USCH FACH FACH RACH CPCH ( FDD only ) 

TDD only TDD only 



MAC - Control 



to MAC -d 



DL Downlink 

TF Transport Format 

TFC Transport Format Combination 

TCTF Target Cliannel Type Field 

(1 ) Sctieduling /Priority handling is applicable for 
CPCH, details are tts. 

(2) In case of CPCH, ASC selection may be applicable 
tor AP preamble. 



UE User Equipment 

UL Uplink 



Figure 4.2.3.1.1 : UE side IVIAC architecture / IVIAC-c/sh details 
4.2.3.2 MAC-d entity - UE Side 

Figure 4.2.3.2.1 shows the UE side MAC-d entity. 

The following functionality is covered: 

Channel switching 

dynamic transport channel type switching is performed by this entity, based on decision taken by RRC. This 
is usually related to a change of radio resources. 

- C/T MUX: 

the CAT MUX is used when multiplexing of several dedicated logical channels onto one transport channel is 
used. An unambiguous identification of the logical channel is included. 

Ciphering: 

Ciphering for transparent mode data to be ciphered is performed in MAC-d. Details about ciphering can be 
found in [10]. 

Deciphering: 

Deciphering for ciphered transparent mode data is performed in MAC-d. Details about ciphering can be 
found in [10]. 

UL TFC selection: 

transport format and transport format combination selection according to the transport format combination 
set (or transport format combination subset) configured by RRC is performed. 



£75/ 



3GPP TS 25.321 version 3.6.0 Release 1999 



12 



ETSI TS 125 321 V3.6.0 (2000-12) 



The MAC-d entity is responsible for mapping dedicated logical channels for the uplink either onto dedicated transport 
channels or to transfer data to MAC-c/sh to be transmitted via common channels. 

One dedicated logical channel can be mapped simultaneously onto DCH and DSCH; 

The MAC-d entity has a connection to the MAC-c/sh entity. This connection is used to transfer data to the MAC-c/sh to 
transmit data on transport channels that are handled by MAC-c/sh (uplink) or to receive data from transport channels 
that are handled by MAC-c/sh (downlink). 

There is one MAC-d entity in the UE. 



to MAC-c/sh 



MAC-d 



n 



C/T MUX 

^=1 ' 



DCCH DTCH DTCH 



Channel switching 

I I I I , 

Deciphering 













C/T 
MUX 




1 





UL: TFC selection 
Ciphering 



1 r 

■ nnH DCh 



DL Downlink 

TF Transport Format 

TFC Transport Format Combination 

Notel : For DCH and DSCH different scheduling 
mechanism apply 



RNTI Radio Network Temporary Identity 

UE User Equipment 

UL Uplink 

Note 2 : The TFC selection place is under discussion 

Note 3 : Ciphering is performed in MAC-d only for 

transparent RLC mode 



Figure 4.2.3.2.1 : UE side IVIAC architecture / IVIAC-d details 

4.2.4 Traffic Related Architecture - UTRAN Side 

Figure 4.2.4.1 illustrates the connectivity between the MAC entities from the UTRAN side. 

It is similar to the UE case with the exception that there will be one MAC-d for each UE and each UE (MAC-d) that is 
associated with a particular cell may be associated with that cell's MAC-c/sh. 

MAC-c/sh is located in the controlling RNC while MAC-d is located in the serving RNC. 

The MAC Control SAP is used to transfer Control information to each MAC entity belongs to one UE. 
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PCCH BCCH CCCH CTCH SHCCH MAC Control 

TDD only 



MAC-c/sh 



n ^ — \ \ r 

PCH FACH FACH RACH CPCH USCH USCH DSCH DSCH 

FDD only TDD only TDD only 



MAC Control DCCH DTCH DTCH 



MAC-d 



lur or local 



~n r 

DCH DCH 



Figure 4.2.4.1 : UTRAN side IVIAC architecture 

4.2.4.1 MAC-c/sh entity - UTRAN Side 

Figure 4.2.4. 1 . 1 shows the UTRAN side MAC-c/sh entity. The following functionality is covered: 

the Scheduling - Priority Handling; 

this function manages FACH and DSCH resources between the UE's and between data flows according to 
their priority. 

- TCTF MUX 

this function represents the handling (insertion for downlink channels and detection and deletion for uplink 

channels) of the TCTF field in the MAC header, and the respective mapping between logical and transport 

channels. 

The TCTF field indicates the common logical channel type, or if a dedicated logical channel is used; 

- UE Id Mux; 

for dedicated type logical channels, the UE Id field in the MAC header is used to distinguish between UEs; 
TFC selection: 

in the downlink, transport format combination selection is done for FACH and PCH and DSCHs; 

demultiplex; 

for TDD operation the demultiplex function is used to separate USCH data from different UEs, i.e. to be 
transferred to different MAC-d entities; 

DL code allocation; 

this function is used to indicate the code used on the DSCH; 

Flow control is provided to MAC-d. 

The RLC provides RLC-PDUs to the MAC, which fit into the available transport blocks on the transport channels. 

There is one MAC-c/sh entity in the UTRAN for each cell; 
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PCCH BCCH SHCCH CCCH CTCH 



MAC - Control 



MAC-c/sh 



Flow Control 
MAC-c/sh / MAC-d 



TCTFMUX/UEIdMUX 



Scheduling / Priority Handling/ Demux 



, I I 

TFC selection 

I I 



TFC selection 



DL: code 
allocation 



l=f 



r-T — r- 

PCH FACH FACH 



DSCH DSCH 



RACH 



CPCH 
(FDD only ) 



to MAC -d 



DL Downlink 

TF Transport Format 

TFC Transport Format Combination 



UE User Equipment 

UL Uplink 



Figure 4.2.4.1.1 : UTRAN side lUIAC architecture / lUIAC-c/sh details 
4.2.4.2 MAC-d entity - UTRAN Side 

Figure 4.2.4.2.1 shows the UTRAN side MAC-d entity. 
The following functionality is covered: 
channel switching: 

dynamic transport channel type switching is performed by this entity, based on decision taken by RRC; 

- C/T MUX box; 

the function includes the C/T field when multiplexing of several dedicated logical channels onto one 
transport channel is used. 

Priority setting; 

This function is responsible for priority setting on data received from DCCH / DTCH; 

- Ciphering; 

Ciphering for transparent mode data to be ciphered is performed in MAC-d. Details about ciphering can be 
found in [10]. 

Deciphering; 

Deciphering for ciphered transparent mode data is performed in MAC-d. Details about ciphering can be 
found in [10]. 

DL Scheduling/Priority handling; 

in the downlink, scheduling and priority handling of transport channels is performed within the allowed 
transport format combinations of the TFCS assigned by the RRC. 
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Flow Control; 

a flow control function exists toward MAC-c/sh to limit buffering between MAC-d and MAC-c/sh entities. 
This function is intended to limit layer 2 signalling latency and reduce discarded and retransmitted data as a 
result of FACH or DSCH congestion. For the lur interface this is specified in [11]. 

A MAC-d entity using common channels is connected to a MAC-c/sh entity that handles the scheduling of the common 
channels to which the UE is assigned and DL (FACH) priority identification to MAC-c/sh; 

A MAC-d entity using downlink shared channel is connected to a MAC-c/sh entity that handles the shared channels to 
which the UE is assigned and indicates the level of priority of each PDU to MAC-c/sh; 

A MAC-d entity is responsible for mapping dedicated logical channels onto the available dedicated transport channels 
or routing the data received on a DCCH or DTCH to MAC-c/sh. 

One dedicated logical channel can be mapped simultaneously on DCH and DSCH. Different scheduling mechanisms 
apply for DCH and DSCH. 

There is one MAC-d entity in the UTRAN for each served UE. 

,,„„ „ . , DCCH DTCH DTCH 

MAC-Control 



to MAC-c/sh 



C/T MUX 
/ Priority 
setting 

Fiow Control 

IVIAC-c/sh / 

IVIAC-d 



Channel switching 

I I I I 

Deciphering 



I I I 




DL scheduling/ 
priority handling 



MAC-d 



f Ciphering 1 f FAUSCH Handling 



DCH 



"T 

DCH 



FAUSCH 



DL Downlink 

TF Transport Format 

TFC Transport Format Combination 



RNTI Radio Network Temporary Identity 

UE User Equipment 

UL Uplink 



Figure 4.2.4.2.1 : UTRAN side l\/IAC architecture / l\/IAC-d details 



4.3 



Channel structure 



The MAC operates on the channels defined below; the transport channels are described between MAC and Layer 1, the 
logical channels are described between MAC and RLC. 

The following subclauses provide an overview, the normative description can be found in [2] and [3] respectively. 

4.3.1 Transport channels 

Common transport channel types are: 
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- Random Access Channel(s) (RACH); 
Forward Access Channel(s) (FACH); 

- Downlink Shared Channel(s) (DSCH); 

Common Packet Channel(s) (CPCH) for UL FDD operation only; 

- Uplink Shared Channel(s) (USCH), for TDD operation only; 

- Broadcast Channel (BCH); 

- Paging Channel (PCH). 
Dedicated transport channel types are: 

- Dedicated Channel (DCH). 

4.3.2 Logical Channels 

The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for 
different kinds of data transfer services as offered by MAC. 

Each logical channel type is defined by what type of information is transferred. 

4.3.2.1 Logical channel structure 

The configuration of logical channel types is depicted in figure 4.3.2.1. 



Control Channel 



Broadcast Control Channel (BCCH) 

Paging Control Channel (PCCH) 
Dedicated Control Channel (DCCH) 

Common Control Channel (CCCH) 
Shared Channel Control Channel (SHCCH) 



Traffic Channel r Dedicated Traffic Channel (DTCH) 

Common Traffic Channel ( CTCH) 

Figure 4.3.2.1 : Logical channel structure 

4.3.2.2 Control Channels 

Following control channels are used for transfer of control plane information only: 

- Broadcast Control Channel (BCCH); 

- Paging Control Channel (PCCH); 

- Common Control Channel (CCCH); 

- Dedicated Control Channel (DCCH); 

- Shared Channel Control Channel (SHCCH). 

4.3.2.3 Traffic Channels 

Following traffic channels are used for the transfer of user plane information only: 
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- Dedicated Traffic Channel (DTCH); 
Common Traffic Channel (CTCH). 

4.3.3 Mapping between logical channels and transport channels 

The following connections between logical channels and transport channels exist: 
BCCH is connected to BCH and may also be connected to FACH; 

- PCCH is connected to PCH; 

- CCCH is connected to RACH and FACH; 

- DCCH and DTCH can be connected to either RACH and FACH, to CPCH and FACH, to RACH and DSCH, to 
DCH and DSCH, or to a DCH; 

DCCH and DTCH can be mapped to the USCH (TDD only); 

- CTCH is connected to FACH; 

- SHCCH is connected to RACH and USCH/FACH and DSCH. 



5 Services provided to upper layers 

This clause describes the different services provided by the MAC to higher layers. For a detailed description of the 
following functions see [2] . 

5.1 Description of Services provided to upper layers 

Data transfer: This service provides unacknowledged transfer of MAC SDUs between peer MAC entities 
without data segmentation. 

Reallocation of radio resources and MAC parameters: This service performs on request of RRC execution of 
radio resource reallocation and change of MAC parameters. 

Reporting of measurements: Local measurements are reported to RRC. 



6 Functions 

6.1 Description of the IVIAC functions 

The functions of MAC include: 

mapping between logical channels and transport channels; 

selection of appropriate Transport Format for each Transport Channel depending on instantaneous source rate; 

- priority handling between data flows of one UE; 

- priority handling between UEs by means of dynamic scheduling; 

- priority handling between data flows of several users on the DSCH and FACH; 

identification of UEs on common transport channels; 

multiplexing/demultiplexing of higher layer PDUs into/from transport blocks delivered to/from the physical 
layer on common transport channels; 
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multiplexing/demultiplexing of higher layer PDUs into/from transport block sets delivered to/from the physical 
layer on dedicated transport channels; 

traffic volume monitoring; 

Dynamic Transport Channel type switching; 

- ciphering for transparent RLC; 

Access Service Class selection for RACH and CPCH transmission. 
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6.2 Relation between MAC Functions and Transport Channels 

6.2.1 Relation between MAC Functions and Transport Channels in 
UTRAN 

Table 6.2.1.1 : UTRAN MAC functions corresponding to the transport channel 



Associate 

d 

MAC 

Functions 


Logical 
Ch 


Tran 

sport 

Ch 


TF 
Sele 
ction 


Priority 
handlin 

g 

betwee 
n users 


Priority 
handlin 

g 

(one 
user) 


Sche 
dulin 

g 


Identi 
ficati 
on of 
UEs 


Mux/ 

Demux on 

common 

transport 

CH 


Mux/ 
Demux 

on 
dedicate 

d 

transpor 

tCH 


Dynamic 
transport 

CH 
switching 


Uplink 
(Rx) 


CCCH 


RAC 
H 












X 






DCCH 


RAC 
H 










X 


X 






DCCH 


CPC 
H 










X 


X 




X 


DCCH 


DCH 














X 




DTCH 


RAC 
H 










X 


X 






DTCH 


CPC 
H 










X 


X 




X 


DTCH 


DCH 














X 




SHCC 
H 


RAC 
H 










X 


X 






SHCC 
H 


use 

H 












X 




X 


DTCH 


use 

H 


X 










X 




X 


DCCH 


use 

H 


X 










X 




X 


Downlink 
(Tx) 


BCCH 


BCH 








X 










BCCH 


FAC 
H 


X 






X 




X 






PCCH 


PCH 


X 






X 










CCCH 


FAC 
H 


X 


X 




X 




X 






CTCH 


FAC 
H 


X 






X 




X 






DCCH 


FAC 
H 


X 


X 




X 


X 


X 






DCCH 


DSC 
H 


X 


X 








X 






DCCH 


DCH 


X 




X 








X 




DTCH 


FAC 
H 


X 


X 




X 


X 


X 




X 


DTCH 


DSC 

H 


X 


X 








X 




X 


DTCH 


DCH 


X 




X 








X 


X 


SHCC 
H 


FAC 
H 


X 


X 




X 




X 






SHCC 
H 


DSC 

H 


X 


X 








X 




X 
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6.2.2 Relation of MAC Functions and Transport CInannels in UE 

Table 6.2.2.1 : UE MAC functions corresponding to the transport channel 



Function 
s 


Logical 
Ch 


Transport 
Ch 


TF 
Selection 


Priority 
handling 

data of 
one user 


Identificati 
on 


Mux/Demux 

on common 

transport 

channels 


Mux/Demux 

on 
dedicated 
transport 
channels 


Dynamic 
transport 

channel 

type 
switching 


Uplink 
(Tx) 


CCCH 


RACH 








X 






DCCH 


RACH 


X 


X 


X 


X 






DCCH 


CPCH 


X 


X 


X 


X 




X 


DCCH 


DCH 


X 


X 






X 




DTCH 


RACH 


X 


X 


X 


X 




X 


DTCH 


CPCH 


X 


X 


X 


X 




X 


DTCH 


DCH 


X 


X 






X 


X 


SHCCH 


RACH 








X 






SHCCH 


USCH 


X 


X 




X 




X 


DCCH 


USCH 


X 


X 




X 




X 


DTCH 


USCH 


X 


X 




X 




X 


Downlink 
(Rx) 


BCCH 


BCH 














BCCH 


FACH 








X 






PCCH 


PCH 














CCCH 


FACH 








X 






CTCH 


FACH 








X 






DCCH 


FACH 






X 


X 






DCCH 


DSCH 








X 






DCCH 


DCH 










X 




DTCH 


FACH 






X 


X 






DTCH 


DSCH 








X 






DTCH 


DCH 










X 




SHCCH 


FACH 








X 






SHCCH 


DSCH 








X 







7 Services expected from physical layer 

The physical layer offers information transfer services to MAC. For detailed description, see [3]. 



8 



Elements for layer-to-layer communication 



The interaction between the MAC layer and other layers are described in terms of primitives where the primitives 
represent the logical exchange of information and control between the MAC layer and other layers. The primitives shall 
not specify or constrain implementations. The MAC is connected to layer 1, RLC and RRC. The following subclauses 
describe the primitives between these layers. 

8.1 Primitives between layers 1 and 2 

The primitives are described in [3]. 



8.2 



Primitives between MAC and RLC 



8.2.1 Primitives 

The primitives between MAC layer and RLC layer are shown in table 8.2.1.1. 
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Table 8.2.1.1 : Primitives between IVIAC layer and RLC layer 



Generic Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


MAC-DATA 


X 


X 






Data, Number of 
transmitted RLC 
PDUs, BO, UE-ID 
type indicator, TD 
(note) 


MAC-STATUS 




X 


X 




No PDU, 
PDU_Size, BO, 
Tx status 


NOTE: TDD only. 



MAC-DATA-Req/Ind: 

MAC-DATA-Req primitive is used to request that an upper layer PDU be sent using the procedures for the 
information transfer service; 

MAC-DATA-Ind primitive indicates the arrival of upper layer PDUs received within one transmission time 
interval by means of the information transfer service. 

MAC-STATUS-Ind/Resp: 

- MAC-STATUS -Ind primitive indicates to RLC for each logical channel the rate at which it may transfer data to 
MAC. Parameters are the number of PDUs that can be transferred in each transmission time interval and the 
PDU size; it is possible that MAC would use this primitive to indicate that it expects the current buffer 
occupancy of the addressed logical channel in order to provide for optimised TFC selection on transport 
channels with long transmission time interval. At the UE, MAC-STATUS-Ind primitive is also used to indicate 
from MAC to RLC that MAC has requested data transmission by PHY (i.e. PHY-DATA-REQ has been 
submitted, see Fig. 1 1 .2.2. 1), or that transmission of an RLC PDU on RACH or CPCH has failed due to 
exceeded preamble ramping cycle counter. 

- MAC-STATUS -Resp primitive enables RLC to acknowledge a MAC-STATUS-Ind. It is possible that RLC 
would use this primitive to indicate that it has nothing to send or that it is in a suspended state or to indicate the 
current buffer occupancy to MAC. 

8.2.2 Parameters 

a) Data: 

it contains the RLC layer messages (RLC -PDU) to be transmitted, or the RLC layer messages that have been 
received by the MAC sub-layer. 

b) Number of transmitted RLC PDUs (indication only): 

indicates the number of RLC PDUs transmitted within the transmission time interval, based on the TFI value. 

c) Buffer Occupancy (BO): 

the parameter Buffer Occupancy (BO) indicates for each logical channel the amount of data that is currently 
queued for transmission (or retransmission) in RLC layer. 

d) RX Timing Deviation (TD), TDD only: 

it contains the RX Timing Deviation as measured by the physical layer for the physical resources carrying the 
data of the Message Unit. This parameter is optional and only for Indication. It is needed for the transfer of 
the RX Timing Deviation measurement of RACH transmissions carrying CCCH data to RRC. 

e) Number of PDU (No_PDU): 

specifies the number of PDUs that the RLC is permitted to transfer to MAC within a transmission time 
interval. 

f) PDU Size (PDU_Size): 
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specifies the size of PDU that can be transferred to MAC within a transmission time interval. 

g) UE-ID Type Indicator: 

indicates the UE-ID type to be included on MAC for a DCCH when it is mapped onto a common transport 
channel (i.e. FACH, RACH or CPCH). 

h) TX_Status: 

when set to value "transmission unsuccessful" this parameter indicates to RLC that transmission of an RLC 
PDU failed in the previous Transmission Time Interval, when set to value "transmission successful" this 
parameter indicates to RLC that the requested RLC PDU(s) has been submitted for transmission by the 
physical layer. 



8.3 



Primitives between IVIAC and RRC 



8.3.1 Primitives 

The primitives between MAC and RRC are shown in table 8.3.1.1. 

Table 8.3.1.1 : Primitives between IVIAC sub-layer and RRC 



Generic Name 


Type 


Parameters 


Request 


Indication 


Response 


Confirm 


CMAC-CONFIG 


X 








UE information elements 
RAB information elements 
TrCH information elements 
RACH transmission control 
elements 

Ciphering elements 
CPCH transmission control 
elements 














CMAC-MEASUREMENT 


X 


X 






Measurement information 
elements (for Request), 
Measurement result (for 
Indication) 


CMAC-STATUS 




X 






Status info. 



CMAC-CONFIG-Req: 

CMAC-CONFIG-Req is used to request for setup, release and configuration of a logical channel, e.g. RNTI 
allocation, switching the connection between logical channels and transport channels, TECS update or 
scheduling priority of logical channel. 

CMAC-MEASUREMENT-Req/Ind: 

CMAC-MEASUREMENT-Req is used by RRC to request MAC to perform measurements, e.g. traffic volume 
measurements; 

- CMAC-MEASUREMENT-Ind is used to notify RRC of the measurement result. 
CMAC-STATUS-Ind: 

- CMAC-STATUS-lnd primitive notifies RRC of status information. 

8.3.2 Parameters 

See TS 25.331 for a detailed description of the UE, RB and TrCH information elements. 

a) UE information elements 
S-RNTI 
SRNC identity 
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C-RNTI 

Activation time 

b) RB information elements 

RB multiplexing info (Transport channel identity, Logical channel identity, MAC logical channel priority) 

c) TrCH information elements 
Transport Format Combination Set 

d) Measurement information elements 
Mode (periodic, event-triggered or both) 
THu 

THl 

Measurement quantity identifiers 

Report Interval 

e) Measurement result 
Mode 

Reporting Quantities 
Event ID (4a or 4b) 

f) Status info 

when set to value ""transmission unsuccessful"" this parameter indicates to RRC that transmission of a TM RLC 
PDU failed (due to e.g. Maximum number of preamble ramping cycles reached for RACH in FDD), when set to 
value "transmission successful" this parameter indicates to RRC that the requested TM RLC PDU(s) has been 
submitted for transmission by the physical layer.. 

g) RACH transmission control elements 

Set of ASC parameters (identifier for PRACH partitions, persistence values) 

Maximum number of preamble ramping cycles M^ax 

Minimum and maximum number of time units between two preamble ramping cycles, NBoimin and Naoimax 

h) Ciphering elements 
Ciphering mode 
Ciphering key 
Ciphering sequence number 

i) CPCH transmission control elements 

CPCH persistency value, P for each Transport Format 

Maximum number of preamble ramping cycles N accessjaiis 

NF_max (Maximum number of frames for CPCH transmission for each Transport Format) 

N_EOT (Number of EOT for release of CPCH transmission) 

Backoff control timer parameters 

Transport Format Set 

Initial Priority Delays 

Channel Assignment Active indication 



9 Elements for peer-to-peer communication 

9.1 Protocol data units 
9.1.1 General 

A MAC PDU is a bit string, with a length not necessarily a multiple of 8 bits. In the drawings in clause 9. 1, bit strings 
are represented by tables in which the first bit is the leftmost one on the first line of the table, the last bit is the rightmost 
on the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order 
of the lines. 

Depending on the provided service, MAC SDUs are bit strings with any non null length, or bit strings with an integer 
number of octets in length. An SDU is included into a MAC PDU from first bit onward. 
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In the UE for the uplink, all MAC PDUs delivered to the physical layer within one TTI are defined as Transport Block 
Set (TBS). It consists of one or several Transport Blocks, each containing one MAC PDU. The Transport Blocks, shall 
be transmitted in the order as delivered from RLC. When multiplexing of RLC PDUs from different logical channels is 
performed on MAC, the order of all Transport Blocks originating from the same logical channel shall be the same as the 
order of the sequence delivered from RLC. The order of the different logical channels in a TBS is set by the MAC 
protocol. 

9.1.2 MAC Data PDU 

MAC PDU consists of an optional MAC header and a MAC Service Data Unit (MAC SDU), see figure 9.1.2.1. Both 
the MAC header and the MAC SDU are of variable size. 

The content and the size of the MAC header depends on the type of the logical channel, and in some cases none of the 
parameters in the MAC header are needed. 

The size of the MAC-SDU depends on the size of the RLC -PDU, which is defined during the setup procedure. 

MAC header MAC SDU 



->♦- 



TCTF 


UE-ld 
type 


UE-ld 


C/T 


MAC SDU 



Figure 9.1 .2.1 : IVIAC data PDU 



9.2 Formats and parameters 



NOTE: MAC header field encodings as specified in this clause with designation "Reserved" are forbidden to be 
used by a sender in this version of the protocol. 

9.2.1 MAC Data PDU: Parameters of the MAC header 

The following fields are defined for the MAC header: 

Target Channel Type Field 

The TCTF field is a flag that provides identification of the logical channel class on EACH and RACH transport 
channels, i.e. whether it carries BCCH, CCCH, CTCH, SHCCH or dedicated logical channel information. The 
size and coding of TCTF for FDD and TDD are shown in tables 9.2.1.1, 9.2.1.2, 9.2.1.3, 9.2.1.4 and 9.2.1.5. 
Note that the size of the TCTF field of EACH for FDD is either 2 or 8 bits depending of the value of the 2 most 
significant bits and for TDD is either 3 or 5 bits depending on the value of the 3 most significant bits. The TCTF 
of the RACH for TDD is either 2 or 4 bits depending on the value of the 2 most significant bits. 

Table 9.2.1.1 : Coding of the Target Channel Type Field on FACH for TDD 



TCTF 


Designation 


000 


BCCH 


001 


CCCH 


010 


CTCH 


01100 


DCCH or DTCH 
over FACH 


01101- 
01111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


100 


SHCCH 


101-111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 
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Table 9.2.1.2: Coding of the Target Channel Type Field on FACH for FDD 



TCTF 


Designation 


00 


BCCH 


01000000 


CCCH 


01000001- 
01111111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


10000000 


CTCH 


10000001- 
10111111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


11 


DCCH or DTCH 
over FACH 



Table 9.2.1.3: Coding of the Target Channel Type Field on USCH or DSCH (TDD only) 



TCTF 


Designation 





SHCCH 


1 


DCCH or DTCH over 
USCH or DSCH 



Table 9.2.1.4: Coding of the Target Channel Type Field on RACH for FDD 



TCTF 


Designation 


00 


CCCH 


01 


DCCH or DTCH 
over RACH 


10-11 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 



Table 9.2.1.5: Coding of the Target Channel Type Field on RACH for TDD 



TCTF 


Designation 


00 


CCCH 


0100 


DCCH or DTCH 
Over RACH 


0101- 
0111 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 


10 


SHCCH 


11 


Reserved 
(PDUs with this coding 
will be discarded by this 
version of the protocol) 



C/T field 

The C/T field provides identification of the logical channel instance when multiple logical channels are carried 
on the same transport channel. The C/T field is used also to provide identification of the logical channel type on 
dedicated transport channels and on FACH and RACH when used for user data transmission. The size of the C/T 
field is fixed to 4 bits for both common transport channels and dedicated transport channels. Table 9.2.1.5a 
shows the 4-bit C/T field. 
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Table 9.2.1.5a: Structure of the C/T field 



C/T field 


Designation 


0000 


Logical channel 1 


0001 


Logical channel 2 






1110 


Logical channel 15 


1111 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 



UE-Id 

The UE-Id field provides an identifier of the UE on common transport channels. The following types of UE-Id 

used on MAC are defined: 

- UTRAN Radio Network Temporary Identity (U-RNTI) may be used in the MAC header of DCCH when 
mapped onto common transport channels; 

Cell Radio Network Temporary Identity (C-RNTI) is used on DTCH, DSCH in FDD mode, and may be used 
on DCCH, when mapped onto common transport channels; 

the UE id to be used by MAC is configured through the MAC control SAP. The lengths of the UE-id field of 
the MAC header are given in table 9.2.1.6. 

Table 9.2.1.6: Lengths of UE Id field 



UE Id type 


Length of UE Id field 


U-RNTI 


32 bits 


C-RNTI 


16 bits 



UE-Id Type 

The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC Headers. 

Table 9.2.1.7: UE-Id Type field definition 



UE-Id Type field 2 bits 


UE-Id Type 


00 


U-RNTI 


01 


C-RNTI 


10 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 


11 


Reserved 

(PDUs with this coding will be 

discarded by this version of 

the protocol) 



9.2.1 .1 MAC header for DTCH and DCCH 

a) DTCH or DCCH mapped to DCH, no multiplexing of dedicated channels on MAC: 

no MAC header is required. 

b) DTCH or DCCH mapped to DCH, with multiplexing of dedicated channels on MAC: 

- C/T field is included in MAC header. 

c) DTCH or DCCH mapped to RACH/FACH: 

- TCTF field, C/T field, UE-Id type field and UE-Id are included in the MAC header. 
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d) DTCH or DCCH mapped to DSCH or USCH: 

the TCTF field is included in the MAC header for TDD only. The UE-Id type and UE-Id are included in the 
MAC header for FDD only. The C/T field is included if multiplexing on MAC is applied. 

e) DTCH or DCCH mapped to DSCH or USCH where DTCH or DCCH are the only logical channels: 

the UE-Id type and UE-Id are included in the MAC header for FDD only. The C/T field is included in the 
MAC header if multiplexing on MAC is applied. 

f) DTCH or DCCH mapped to CPCH: 

UE-Id type field and UE-Id are included in the MAC header. The C/T field is included in the MAC header if 
multiplexing on MAC is applied. 



Case a): 

Case b): 
Case c and d): 

Case e and f): 



MAC SDU 



C/T 



MAC SDU 



TCTF 



UE-Id 
type 



UE-Id I C/T 



MAC SDU 



UE-Id 
type 



UE-Id C/T I 



MAC SDU 



Figure 9.2.1 .1 .1 : lUIAC Data PDU formats for DTCH and DCCH 



9.2.1.2 MAC header for BCCH 

a) BCCH mapped to BCH: 

no MAC header is included. 

b) BCCH mapped to EACH: 

- the TCTF field is included in MAC header. 

Case a) : 



MAC SDU 



Case b): 



TCTF 



MAC SDU 



Figure 9.2.1 .2.1 : IVIAC Data PDU formats for BCCH 



9.2.1 .3 MAC header for PCCH 

There is no MAC header for PCCH. 

9.2.1.4 MAC header for CCCH 

CCCH mapped to RACH/FACH: 

- TCTF field is included in MAC header. 



TCTF 



MAG SDU 



Figure 9.2.1 .4.1 : lUIAC Data PDU formats for CCCH 
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9.2.1 .5 MAC Header for CTCH 

The TCTF field is included as MAC header for CTCH as shown in figure 9.2.1.5.1. 



TCTF 



MAC SDU 



Figure 9.2.1.5.1 : IVIAC Data PDU format for CTCH 

9.2.1 .6 MAC Header for SHCCH 

The MAC header for SHCCH is as shown in figure 9.2.1.6.1. 

a) SHCCH mapped to RACH and USCH/FACH and DSCH: 

TCTF has to be included. 

b) SHCCH mapped to RACH and USCH/FACH and DSCH, where SHCCH is the only channel. 



Case a): 
Case b): 



TCTF 



MAC SDU 



MAC SDU 



Figure 9.2.1.6.1 : lUIAC Data PDU format for SHCCH 



10 Handling of unknown, unforeseen and erroneous 
protocol data 

The list of error cases is reported below: 

a) Use of reserved coding in the MAC header 

If the MAC entity receives a Data PDU with a header field using a value marked as reserved for this version of 
the protocol, it shall discard the PDU, unless explicitly mentioned otherwise. 

b) Inconsistent MAC header 

If the MAC entity receives a data PDU with a header inconsistent with the configuration received from RRC, it 
shall discard the PDU. E.g.: In case DTCH is mapped to RACH/FACH, the MAC entity shall discard a PDU 
with a C/T field indicating a logical channel number that is not configured. 



1 1 Elementary procedures 

1 1 .1 Traffic volume measurement for dynamic radio bearer 
control 

Dynamic radio bearer control is performed in RRC, based on the traffic volume measurement reported by MAC. Traffic 
volume information is gathered and measured in MAC layer and the result is reported from MAC layer to RRC layer. 

Traffic volume monitoring procedure in MAC is shown in figure 11.1.1. MAC receives RLC PDUs together with 
information of RLC transmission buffer. Every TTI, MAC compares the amount of data corresponding to a Transport 
Channel with the thresholds set by RRC. If the value is out of range, MAC indicates the measurement reports on traffic 
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volume status to RRC. Thereby, RRC can be informed the traffic volume status of each transport channel, and therefore 
can take proper action for new radio bearer configuration accordingly. 

RRC requests MAC measurement report with the primitive CMAC-Measure-REQ including following parameters. 

Measurement information elements. 

- Mode 

Indicates whether the report should be periodic, or event-triggered 

THu (If Event ID = 4a, then Reporting Threshold is Upper Threshold.) 

Upper threshold value for every transport channel, applicable when mode is event-triggered 

THl (If Event ID = 4b, then Reporting Threshold is Lower Threshold.) 

Lower threshold value for every transport channel, applicable when mode is event-triggered 

Measurement quantity identifiers 

Indicates what should be reported to RRC layer 

For each RB, Buffer Occupancy (mandatory). Variance (optional), or Average (optional) 

Report Interval 

Indicates the report interval, applicable when report mode is periodic 

MAC receives RLC PDUs with the primitive MAC-Data-REQ including following parameters. 

- Data (RLC PDU) 

Buffer Occupancy (BO) 

The parameter Buffer Occupancy (BO) indicates the amount of data that is currently queued for transmission (or 

retransmission) 

MAC receives measurement information elements with the primitive CMAC-Measure-REQ that includes parameters 
such as Mode, report interval, and THl and THu for each transport channel. Whenever MAC receives RLC PDUs from 
different RLC entities, it is notified by RLC amount of data queued in RLC transmission buffer. If the mode is event- 
triggered, MAC compares the amount of data to be transmitted on a transport channel with threshold values passed by 
RRC, THl and THu. In case that the measured value is out of range, MAC reports the status of result of comparison 
and status of each RB to RRC. On the other hand, if the mode is periodic, MAC reports measurement result to RRC 
periodically. Measurement result can contain average and variance as well as amount of data for each RB as follows. 

Measurement result. 

- Mode 

Periodic, or event-triggered 

Reporting Quantity 

For each RB, Buffer Occupancy (mandatory). Variance (optional), and Average (optional) 

- Event ID 

Indicates overflow or underflow for each transport channel, applicable when mode is event-triggered 

Event 4a: RLC buffer payload exceeds an absolute threshold 
- Event 4b: RLC buffer payload becomes smaller than an absolute threshold 
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(^ Start ^ 



Get the measurement information from RRC: 
Mode, THu, THl, Report Interval, etc 



Check traffic volume of transport channels 



N 





Report 
Measurement 
Result to RRC 



Wait TTI 



Figure 11.1.1 : Traffic volume measurement/report procedure in IVIAC 



1 1 .2 Control of RACH transmissions 

The MAC sublayer is in charge of controlling the timing of RACH transmissions on transmission time interval level 
(i.e. on 10 ms-radio frame level; the timing on access slot level is controlled by LI). Note that retransmissions in case of 
erroneously received RACH message part are under control of higher layers, i.e. RLC, or RRC for CCCH (and SHCCH 
for TDD). 

11 .2.1 Access Service Class selection 

The physical RACH resources (i.e. access slots and preamble signatures for FDD, timeslot and channelisation code for 
TDD) may be divided between different Access Service Classes in order to provide different priorities of RACH usage. 
It is possible for more than one ASC or for all ASCs to be assigned to the same access slot/signature space. 
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Access Service Classes are numbered in the range < / < NumASC < 7 (i.e. the maximum number of ASCs is 
NumASC+1 = 8). An ASC is defined by an identifier / that defines a certain partition of the PRACH resources and an 
associated persistence value f ,. A set of ASC parameters consists of NumASC+1 such parameters (i, P,), i = Q, ..., 
NumASC. The PRACH partitions and the persistence values P, are derived by the RRC protocol from system 
information (see TS 25.331 [7]). The set of ASC parameters is provided to MAC with the CMAC-Config-REQ 
primitive. The ASC enumeration is such that it corresponds to the order of priority (ASC = highest priority, ASC 7 = 
lowest priority). ASC shall be used in case of Emergency Call or for reasons with equivalent priority. 

At radio bearer setup/reconfiguration each involved logical channel is assigned a MAC Logical channel Priority (MLP) 
in the range 1,...,8. When the MAC sublayer is configured for RACH transmission in the UE, these MLP levels shall be 
employed for ASC selection on MAC. 

The following ASC selection scheme shall be applied, where NumASC is the highest available ASC number and 
MinMLP the highest logical channel priority assigned to one logical channel: 

- in case all TBs in the TB set have the same MLP, select ASC = min(NumASC, MLP); 

in case TBs in a TB set have different priority, determine the highest priority level MinMLP and select 
ASC = min(NumASC, MinMLP). 

1 1 .2.2 Control of RACH transmissions for FDD mode 

The RACH transmissions are controlled by the UE MAC sublayer as outlined in figure 11.2.2.L 

NOTE: The figure shall illustrate the operation of the transmission control procedure as specified below. It shall 
not impose restrictions on implementation. MAC controls the timing of each initial preamble ramping 
cycle as well as successive preamble ramping cycles in case that none or a negative acknowledgement is 
received on AICH. 

MAC receives the following RACH transmission control parameters from RRC with the CMAC- CONFIG- Req 
primitive: 

a set of Access Service Class (ASC) parameters, which includes for each ASC, i=0,. .., NumASC an 
identification of a PRACH partition and a persistence value Pi (transmission probability); 

maximum number of preamble ramping cycles M^.^^; 

- range of backoff interval for timer Tboi, given in terms of numbers of transmission 10 ms time intervals Neoimax 
and NBoimin, applicable when negative acknowledgement on AICH is received. 

When there is data to be transmitted, MAC selects the ASC from the available set of ASCs, which consists of an 
identifier i of a certain PRACH partition and an associated persistence value P,. The procedure to be applied for ASC 
selection is described in subclause 11.2.1. 

Based on the persistence value P„ the UE decides whether to start the LI PRACH transmission procedure (see 
TS 25.214) in the present transmission time interval or not. If transmission is allowed, the PRACH transmission 
procedure (starting with a preamble power ramping cycle) is initiated by sending of a PHY-ACCESS-REQ primitive. 
MAC then waits for access information from LI via PHY-ACCESS-CNF primitive. If transmission is not allowed, a 
new persistency check is performed in the next transmission time interval. The persistency check is repeated until 
transmission is permitted. 

When the preamble has been acknowledged on AICH, LI access information with parameter value "ready for data 
transmission" is indicated to MAC with PHY-ACCESS-CNF primitive. Then data transmission is requested with PHY- 
DATA-REQ primitive, and the PRACH transmission procedure shall be completed with transmission of the PRACH 
message part according to LI specifications. Successful completion (TX status) of the MAC transmission control 
procedure shall be indicated to higher layer. 

When PHY indicates that no acknowledgement on AICH is received while the maximum number of preamble 
retransmissions is reached (defined by parameter Preamble_Retrans_Max on LI), a new persistency test is performed in 
the next transmission time interval. The timer T2 ensures that two successive persistency tests are separated by at least 
one 10 ms time interval. 
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In case that a negative acknowledgement has been received on AICH a backoff timer Tboi is started. After expiry of the 
timer, persistence check is performed again. Backoff timer Tboi is set to an integer number Nboi of 10 ms time 
intervals, randomly drawn within an interval < NBoimin ^ Nboi ^ NBoimax (with uniform distribution). NBoimin and 
Nboi max may be set equal when a fixed delay is desired, and even to zero when no delay other than the one due to 
persistency is desired. 

Before a persistency test is performed it shall be checked whether any new RACH transmission control parameters have 
been received from RRC with CMAC-CONFIG-Req primitive. The latest set of RACH transmission control parameters 
shall be applied. 

If the maximum number of preamble ramping cycles M^ax is exceeded, failure of RACH transmission shall be reported 
to higher layer. 

Both, transmission failure and successful completion of the MAC transmission control procedure, shall be indicated 
individually for each logical channel of which data was included in the transport block set of that access attempt. When 
transparent mode RLC is employed (i.e. for CCCH), transmission status is reported to RRC with CMAC-STATUS-Ind 
primitive. For logical channels employing acknowledged or unacknowledged mode RLC, transmission status is reported 
to RLC with MAC-STATUS-Ind primitive. 
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Figure 11.2.2.1: RACIH transmission control procedure (UE side, informative) 
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1 1 .2.3 Control of RACH transmissions for TDD 

The RACH transmissions are performed by the UE as shown in figure 1 1.2.3.1. 

NOTE: The figure shall illustrate the operation of the transmission control procedure as specified below. It shall 
not impose restrictions on implementation. 

MAC receives the following RACH transmission control parameters from RRC with the CMAC-Config-REQ 
primitive: 

a set of Access Service Class (ASC) parameters, which includes for each ASC, i=0,. . .,NumASC an 
identification of a PRACH partition and a persistence value P, (transmission probability). 

When there is data to be transmitted, MAC selects the ASC from the available set of ASCs, which consists of an 
identifier / of a certain PRACH partition and an associated persistence value P,. The procedure to be applied for ASC 
selection is described in subclause 11.2.1. 

Based on the persistence value P, the UE decides whether to send the message on the RACH. If transmission is allowed, 
the PRACH transmission procedure is initiated by sending of a PHY-Data-REQ primitive. If transmission is not 
allowed, a new persistency check is performed in the next transmission time interval. The persistency check is repeated 
until transmission is permitted. 

Successful completion (TX status) of the MAC transmission control procedure shall be indicated to higher layer 
individually for each logical channel of which data was included in the transport block set of that access attempt. When 
transparent mode RLC is employed (i.e. for CCCH), transmission status is reported to RRC with CMAC-STATUS-lnd 
primitive. For logical channels employing acknowledged or unacknowledged mode RLC, transmission status is reported 
to RLC with MAC-STATUS-lnd primitive. 
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Figure 1 1 .2.3.1 : RACH transmission control procedure for TDD (UE side, informative) 

1 1 .3 Control of CPCH transmissions for FDD 

The MAC layer controls the timing of CPCH transmissions on transmission time interval level (i.e. on 10, 20, 40 or 80 
ms level); the timing on access slot level is controlled by LI. MAC controls the timing of each initial preamble ramping 
cycle as well as successive preamble ramping cycles. Note that retransmissions in case of erroneously received CPCH 
message part are under control of higher layers. The CPCH transmissions are performed by the UE as illustrated in 
figures 11.3.1 and 11.3.2. Figure 11.3.1 procedure is used for access to CPCH channel. Figure 11.3.2 procedure is used 
for CPCH Message transmission on the CPCH channel obtained using the access procedure. 

MAC receives the following CPCH transmission control parameters from RRC with the CMAC-Config-REQ primitive: 

- persistence values, P (transmission probability for each Transport Format (TF)); 

N_access_fails, maximum number of preamble ramping cycles; 

NF_max, maximum number of frames for CPCH transmission for each TF; 

N_EOT (Number of EOT for release of CPCH transmission); 

Backoff control timer parameters; 

Transport Format Set; 
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Initial Priority Delays; 

Channel Assignment Active indication. 

The MAC procedure for CPCH access shall be invoked when the UE has data to transmit. The steps for this procedure 
are listed here: 

1 . the UE shall get all UL transmit parameters (CPCH Set Info, P values, Initial Priority Delays, N_access_fails, 
NF_max, N_EOT etc) from RRC; 

2. the UE shall reset counter M, EOT counter and Frame Count Transmitted (FCT) upon entry to the initial access 
procedure; 

3. if counter M is equal to N_access_fails, the UE shall indicate an access failure error to higher layer and the 
CPCH access procedure ends. Access failure is reported to RLC with MAC-STATUS-Ind primitive individually 
for each logical channel of which data was included in the transport block set that could not be transmitted. If 
counter M is less than N_access_fails, the UE shall send a PHY-CPCH_Status-REQ to Layer 1 to obtain CPCH 
TF subset status. If Layer 1 returns an error message, the UE shall increment counter M and the procedure shall 
continue from step 3. If Layer 1 returns a PHY-CPCH_Status-CNF message, which includes a TF subset 
indicating the currently available TFs of the requested TF subset, the procedure shall continue from step 4; 

4. the UE shall initialise the Busy Table with the CPCH TF subset status from Layer 1. Those TFs in the TF subset 
of the Layer 1 PHY-CPCH_Status-CNF response will be marked available. All other TFs will be marked busy; 

5. if all TFs are not marked busy, the procedure shall proceed from step 6. If all TFs are marked busy, the UE shall 
reset and start timer Tbocl, wait until timer expiry, and increment counter M. The procedure shall continue from 
step 3; 

6. the UE shall update all UL transmit parameters from RRC; 

7. UE shall select a TF from the set of available TFs listed in the Busy Table. UE shall use the CPCH channel 
capacity (transport block set size, NF_max, and TTI interval), and Busy Table information to select one CPCH 
TF for LI to access. The UE may select a TF, which uses a lower data rate and a lower UL Tx power than the 
maximum UL Tx power allowed. UE shall implement a test based on the Persistence value (P) to determine 
whether to attempt access to the selected CPCH TF. If access is allowed, the procedure shall continue from step 
9. If the P test does not allow access, the procedure shall continue from step 8; 

8. the selected CPCH TF shall be marked busy in the Busy Table. If all TFs are marked busy, the UE shall reset 
and start timer Tbocl, wait until timer expiry, increment counter M, and continue from step 3. If all TFs are not 
marked busy, the UE shall resume the procedure from step 6; 

9. the UE may implement an initial delay based on ASC of the data to be transmitted, then shall send a PHY- 
Access-REQ with the selected TF to LI for CPCH access . After the UE has sent the access request to LI , LI 
shall return a PHY-Access-CNF including one of five access indications to MAC as shown in figure 11.3.1. If 
the LI access indication is that access is granted, then UE shall continue from step 14. For the cases of the other 
Layer 1 responses, the procedure shall continue from step 10, 11, or 12 respectively. 

10. if LI access indication is no AP-AICH received or no CD-AICH received, the UE shall reset and start timer 
Tboc3, wait until timer expiry, and increment counter M. The UE shall proceed from step 3; 

1 1 . if LI access indication is AP-AICH_nak received, the UE shall reset and start timer Tboc2, wait until timer 
expiry. If Channel Assignment (CA) is active, the UE shall proceed from step 13. If Channel Assignment (CA) is 
not active, the procedure shall continue from step 8; 

12. if LI access indication is CD-AICH signature mismatch, the UE shall reset and start timer Tboc4, wait until 
timer expiry, and increment counter M. The procedure shall continue from step 3; 

13. the UE shall increment counter M. The procedure shall continue from step 3. 



14. the UE shall build a transport block set for the next TTI; 

15. if the sum of the Frame Count Transmitted counter plus N_TTI (the number of frames in the next TTI) is greater 
than NF_max, the UE shall exit this procedure and start the MAC procedure for CPCH transmission of the first 
TTI. This shall release the CPCH channel in use and the UE will contend again for a new CPCH channel to 
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continue transmission. If the sum of the Frame Count Transmitted counter plus N_TTI is less than or equal to 
NF_max, the UE shall send a PHY-Data-REQ with the transport block set to LI to continue transmission on the 
CPCH channel which has previously been accessed; 



16. if the LI returns PHY-Status-IND indicating normal transmission, the procedure shall continue from step 17. If 
LI returns PHY-Status-IND indicating abnormal situation the UE shall execute an abnormal situation handling 
procedure and the CPCH message transmission procedure ends. Reasons for abnormal situation may include the 
following: 

emergency stop was received; 

start of Message Indicator was not received; 

- LI hardware failure has occurred; 

out of synch has occurred; 

17. the UE shall increment the Frame Count Transmitted (FCT) counter by N_TTI just transmitted and indicate TX 
Status "transmission successful" to RLC individually for each logical channel of which data was included in the 
transport block set. If the UE has more data to transmit, the procedure shall continue from step 14; 

18. the UE shall build the next TTI with zero sized transport block set. If the sum of the Frame Count Transmitted 
counter plus N_TTI is less than or equal to NF_max and if the sum of the EOT counter plus N_TTI is less than 
or equal to N_EOT, the procedure shall continue from step 19. Otherwise, the procedure ends; 

19. UE shall send a PHY-Data-REQ with zero sized transport block set to LI to stop transmission on the CPCH 
channel which has previously been accessed, both the EOT and the FCT counters shall be incremented by 
N_TTI and the procedure shall continue from step 18. 

Table 11.3: CPCH Backoff Delay Timer Values 



Timer 


Based on parameter 


Fixed/random 


Tboci (all Busy) 


NF_bo_all_busy 


Random 


Tboc2 (channel Busy) 


NS_bo_busy 


Fixed 


Tboc3 (no AICH) 


NF bo no aich 


Fixed 


Tboc4 (mismatch) 


NF_bo_mismatch 


Random 



For Tboc4, UE shall randomly select a timer value at each execution of the timer. A uniform random draw shall be made 
to select an integer number of frames within the range [0, NF_bo_mismatch]. For Tboci, UE would randomly select a 
timer value at each execution of the timer. A uniform random draw shall be made to select an integer number of frames 
within the range [0, NF_bo_all busy] . 

NOTE: Backoff parameter range and units are specified in TS 25.331, RRC Protocol Specification. 
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Update all CPCH Transmit Parameters from RRC. 



Select available CPCH 
TF, R(random) 




N 



Execute priority delay. Send 

PHY-Access-REQ for selected 

TF to Layer 1 for access attempt. 



I 



> Mark TF Busy 





Wait Tboc2 




Wait Tboc4 



Layer 1 PHY-Access-CNF responses: 



CPCH Message TransmissioiT 



A: no AP_AICH received 

B: no CD_AICH received 

C: access granted 

D: CD_AICH signature mismatch, collision 

E: AP AICH nak received 



Figure 11.3.1 : CPCH transmission control procedure for access (informative) 
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Figure 11.3.2: CPCH transmission control procedure for CPCH IVIessage Transmission (informative) 

1 1 .4 Transport format combination selection in UE 

RRC can control the scheduling of uplink data by giving a priority value between 1 and 8 for each logical channel 
where 1 is the highest priority and 8 the lowest. The selection of TFC in the UE shall be done according to the priorities 
between logical channels indicated by RRC. Logical channels have absolute priority i.e. the UE shall maximize the 
transmission of high priority data. 

The scheme is performed each time a TFC selection is performed, i.e., each time the shortest configured TTI begins. 
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Consider the priorities N1..N2 (N2>N1) where data is available for transmission at the time the TFC selection is 
performed. Let SI and S2 be sets of TFCs. 

1 . Let S2 be the set of all TFCs in the TFCS that can be supported at the current UE maximum transmitter power. 

2. Priority N = NL 

3. S1=S2. 

4. If S 1 contains one single TFC, select this TFC and end the procedure. 

5. Let S2 be the set of all TFCs in S 1 that allow the highest amount of available priority N data bits to be 
transmitted. 

6. N = N+ L 

7. If N > N2, select anyone of the TFCs in S2 and end the procedure. 

8. Go back to step 3. 

The above rules for TFC selection in the UE shall apply to DCH, and the same rules shall apply for TF selection on 
RACH and CPCH. 

When the UE output power is approaching the UE maximum transmit power and the inner loop for power control can 
no longer be maintained for coverage reasons, the UE shall adapt to the TFC corresponding to the next lower bit rate, 
i.e. the TFC with the present total bit rate shall not be used. If the bit rate of a logical channel carrying data from a 
codec supporting variable-rate operation is impacted, the codec data rate shall be adopted accordingly. 

The UE shall continuously estimate whether the maximum transmitter power is sufficient to support the temporarily 
blocked TFC. When the maximum transmitter power is sufficient, the temporarily blocked TFC shall again be 
considered in the TFC selection. 

The maximum UE power is defined in [25.331]. 



11.5 Ciphering 



The ciphering function is performed in MAC (i.e. only in MAC-d) if a radio bearer is using the transparent RLC mode. 
The data unit that is ciphered is the MAC SDU and this is shown in Figure ILS.l below. 



MAC header 



MAC SDU 



A 


► 


< 


► 


TCTF 


UE-ld 
type 


UE-ld 


C/T 


MAC SDU 



Ciphering Unit 

Figure 1 1 .5.1 : Ciphering unit for a IVIAC PDU 

The ciphering algorithm and key to be used are configured by upper layers [7] and the ciphering method shall be 
applied as specified in [10]. 

The parameters that are required by MAC for ciphering are defined in [10] and are input to the ciphering algorithm. The 
parameters required by MAC which are provided by upper layers [7] are listed below: 

MAC-d HEN (Hyper frame number for radio bearers that are mapped onto transparent mode RLC) 

- BEARER (Radio Bearer ID) 

- CK (Ciphering Key) 
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